Modern processors are extremely complicated systems. Most modern processors employ a pipelined architecture, where sequential instructions, each having multiple execution steps, are overlapped in execution. Many processors, known as “superscalar” processors, include two or more separate pipelines for parallel instruction execution. To avoid stalls in the pipeline due to branch instructions, most processors employ various forms of branch prediction, with speculative fetching and execution of instructions when branches are predicted taken. To improve performance, many modern processors separate logical register addresses from the corresponding physical memory storage registers, known as register renaming. To provide programs the illusion of unlimited, fast memory, many processors execute code in a virtual address space, translating addresses to one or more physical address spaces as data traverses a memory hierarchy (e.g., register, cache, main memory). With such complexity, the execution of code within a modern processor is very difficult to accurately track and validate. In particular, anomalies may be very hard to debug.
In addition, the software that executes on modern processors is itself extremely complex. With of the advent of Reduced Instruction Set Computing (RISC) processor architectures, much of the computational and logical complexity of computing migrated from processor instructions to optimizing compilers. That is, compilers build complex operations from a relatively small set of processor instructions, each of which is optimized for a particular, specific function. This results in a more lengthy and complex sequence of instructions, including, e.g., logical, arithmetic, load/store, and branch operations, for a given computational task. Such complex code can be difficult to debug when errors cause anomalous program behavior.
To assist in the daunting task of debugging complex code executing on a complex processor, debugging tools are built into many processors. These may comprise address and data comparators for identifying specific instructions and/or data patterns. The debug tools may additionally include address range comparators, so that the debugging or tracing may be limited to predetermined code segments. Other debug tools may include counters, sequencers, and the like, to provide flexibility in specifying the conditions that specify breakpoints and/or trace triggers. Trace information may be provided off-chip, such as via a dedicated bus, or may be stored in a dedicated on-chip buffer. Breakpoints may trigger one or more external signals, such as to arm and/or trigger a logic analyzer or illuminate an LED; may cause an exception, branching code execution to a debugging routine; or may simply halt execution, allowing the contents of various registers and caches to be inspected. These debugging tools, which are not utilized during normal processor execution, are designed into the processor circuits in such a way as to minimize impact on processor performance and power consumption.
Programmers may explicitly set the proper instruction set operating mode in software, prior to executing instructions according to the relevant instruction set encoding. However, errant software may at times branch to a particular instruction address that was intended to be executed while in one instruction set operating mode, but while the processor is actually in some other instruction set operating mode. In such a case, the processor may attempt to execute the instruction at that address using the improper instruction set decoding, leading to incorrect results.
For example, some versions of the ARM processor architecture include at least two instruction set operating modes: a 32-bit ARM mode and a 16-bit Thumb mode. Table 1 lists a code snippet of ARM instructions:
TABLE 1ARM mode instruction encoding000096F0cpyr4, r0000096F4bl0xA8A0000096FCcpyr1, r400009700ldrr0, [r0, #0x8]
Table 2 lists the same code interpreted in Thumb mode:
TABLE 2Thumb mode instruction encoding000096F0andr0, r0000096F2b0x9A36000096F4lslr1, r5, #0x11000096F6add.wr0, r0, r4, lsl #0x4000096FAb0x9A3E000096FClslr0, r1, #0x0000096FEb0x922200009700andr0, r2
Note, in particular, the branch instructions at 96F2, 96FA, and 96FE. Due to erratic branching, it may be difficult to ascertain the point at which an error caused the ARM code of Table 1 to be interpreted in Thumb mode as in Table 2, and hence to debug the error. This difficulty arises because prior art debug circuits do not include the processor instruction set operating mode as an input to the logic that triggers breakpoints, initiates traces, and of the like.
Most processors that support two or more operating “modes,” such as supervisor and user modes, or real and protected modes, switch between the modes by causing an exception and branching to a mode switching routine. This operation is easily detected using prior art debugging tools and software by setting a breakpoint or beginning a trace on the instruction address of the mode switching routine. A processor switching instruction set operating modes without causing an exception is one example of code behavior that is difficult to diagnose with prior art debugging tools, that do not include the processor instruction set operating mode as a consideration in triggering breakpoints, initiating traces, and the like.